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REMARKS 

By this amendment, claims 1-45 are pending. No claim is canceled, currently amended, or 
newly presented. 

The final Office Action mailed December 13, 2006 rejected claims 1, 2, 4, 5, 8, 9, 1 1, and 
15 under 35 U.S.C. § 102(e) as anticipated by Hammarstrom et al. (US 6,044,142), claims 16-45 
under 35 U.S.C. § 102(e) as anticipated by Havens (US 5,881,144), and claims 3, 5, 6, 10, 12, 
and 13 as obvious under 35 U.S.C. § 103 based on Hammarstrom et al. (US 6,044,142) in view 
of Pullen et al (US 6,198,813). 

Applicants appreciate the indication that claims 7 and 14 are allowable if recast in 
independent form. 

REJECTION OF CLAIMS 1, 2, 4, 5, 8, 9, 11, 15 UNDER 35 U.S.C. § 102(e) 

Independent claims 1, 8, and 15 recite (emphasis added), "creating a customer 
application file using a customer-specified sequence of said service-independent building 
blocks in a server of said telecommunications network, wherein a set of customer specific data 
is defined for use as inputs into said set of service-independent building blocks." 

In an attempt to meet these claim limitations, at page 3 of the Final Rejection, the 
Examiner relies on various portions of Hammarstrom et al. 

The creation of a customer application file using a customer-specified sequence of said 

service-independent building blocks in a server is said to be taught at col. 2, lines 10-14, with the 

"service management system" (SMS) alleged to perform this function. Applicants respectfully 

disagree. The cited portion of Hammarstrom et al. provides that 

Each new service is defined, specified, developed, and tested 
in a special service creation environment linked to a service management 
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system (SMS) and then simply downloaded to the service control point. 
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While it is not necessarily contested that each new service may be composed of "reusable 
components called service independent building blocks (SIBs)" (col. 1, line 66-col. 2, line 1), 
there is nothing in the portion of the reference cited by the Examiner about the SMS "creating a 
customer application file using a customer-specified sequence of said service-independent 
building blocks in a server." The "service creation environment" noted in Hammarstrom et al. 
is not even necessarily on, or in, a server, as required by the claims. 

The Examiner next cites col. 3, line 47-col. 4, line 10, of Hammarstrom et al. for the 
teaching of "creating a customer application file," explaining that "a user creates a customer 
specific application using the service-independent building blocks based on information provided 
by the customer." Again, Applicants respectfully disagree. Hammarstrom et al. provides for a 
specific application by using one or more service independent blocks to implement a command, 
but it is an "operator-initiated command" (see col. 3, line 63), and not a "customer-specified 
sequence," as required by the instant claims. Hammarstrom et al. makes this very clear as it is the 
intention of this reference "to provide cooperation between live operators and automated IN- 
based services (col. 3, lines 1 1-12). 

The Examiner asserts, at page 9 of the Final Rejection, that 

. . .it is clear that the operator is creating a customer specific sequence 
of SIBBs since the operator is connecting them for the caller (customer). 
The operator will obtain the customers [sic, customer's] needs (customer 
specific data) and will use that information to determine the inputs for 
the service-independent building blocks. 

On pages 9-10 of the Final Rejection, the Examiner acknowledges that the operator, and not the 

actual customer, physically creates the service, but the Examiner asserts that because: 

the inputs are defined by the customer's needs then HammarstrSm meets 

12 



10/613,054 Patent 

the claimed limitations of "creating a customer application file using a 
customer-specified sequence of said service-independent building blocks 
in a server of said telecommunications network, wherein a set of customer 
specific data is defined for use as inputs input said set of service-independent 
building blocks." 

Applicants appreciate the Examiner's explanation of how Hammarstrom et al. is being 
read on the claims, but Applicants respectfully disagree that an operator assisted system as in 
Hammarstrom et al, wherein the operator, and not the customer, actually causes the execution of 
one or more service independent building blocks via an operator-initiated command, can be 
considered a disclosure of a "customer-specified sequence of said service-independent building 
blocks," as claimed. However, assuming, arguendo, that the operator assistance in 
Hammarstrom et al. in sequencing the service-independent building blocks in accordance with a 
customer's needs may be considered "a customer-specified sequence of said service-independent 
building blocks," the subject matter of the instant claims is still not anticipated by Hammarstrom 
et al. This is so because, by the terms of the claims, "a customer-specified sequence of said 
service-independent building blocks" is required to be used in "creating a customer application 
file" and there is no such "customer application file" in Hammarstrom et al, let alone a 
"customer application file" created by "using a customer-specified sequence of said service- 
independent building blocks in a server..., wherein a set of customer specific data is defined for 
use as inputs into said set of service-independent building blocks." The operator in 
Hammarstrom et al. may combine service logic and service data in a particular service- 
independent building block (SIBB) sequence, but it is unreasonable to characterize this as being 
either an "input" or "customer-specific," as claimed. 

Even if one were to assume, as accurate, which Applicants do not, the Examiner's 
assessment that the operator in Hammarstrom et al. is creating a customer specific sequence of 
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SIBBs since the operator is connecting them for the customer and the operator obtains the 
customer's needs and uses that information to determine the inputs for the service-independent 
building blocks (page 9 of the Final Rejection), there is still no creation of "a customer 
application file," as claimed, in Hammarstrom et al. There is no such "file" created in 
Hammarstrom et al. because the operator in Hammarstrom et al. merely sets a sequence of 
operations into motion through an operator-initiated command, but there is no indication in 
Hammarstrom et al. that any "customer application file" is being created and there is certainly no 
indication of any such file being created by "using a customer-specified sequence of said service- 
independent building blocks." Accordingly, Hammarstrom et al. cannot be said to anticipate 
claims 1, 2, 4, 8, 9, 11, and 15. 



REJECTION OF CLAIMS 3, 5, 6, 10, 12, AND 13 UNDER 35 U.S.C. § 103 



Since Pullen et al. was cited by the Examiner merely as a teaching of defining rules under 
which service-independent building blocks operate and of defining inputs and outputs for each 
set of service-independent building blocks, and Pullen et al. does not provide for the deficiencies 
of Hammarstrom et al. noted supra, no prima facie case of obviousness has been established by 
the Examiner and a withdrawal of this rejection is respectfully requested. 

In addition, these dependent claims are separately patentable on their merits. For 
example, Pullen et al. fails to teach storing of a set of data in an advanced network database, let 
alone storing a set of "customer specific data" as specified in claim 5; and Pullen et al. fails to 
teach assigning an identification number associated with a customer specific data file, as 
specified in claims 6 and 13. 
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REJECTION OF CLAIMS 16-45 UNDER 35 U.S.C. § 102(e) 



Independent claims 16, 21, 27, 32, 38, and 42 recite either a method or system for 
supporting an "interactive voice response (IVR) service." On its face, the reference to Havens 
is not an anticipatory reference because Haven is concerned with Intelligent Networks (IN), and 
IN subscriptions and services, rather than IVR services. An intelligent network (IN) is a service- 
independent telecommunications network. That is, intelligence is placed in computer nodes that 
are distributed throughout the network, providing the network operator with the means to 
develop and control services more efficiently. In contrast, IVR, is a computerized system that 
allows a person, typically a telephone caller, to select options from a voice menu and otherwise 
interact with the computer phone system. While there may be some similarities and 
overlapping of the types of functions performed by these two types of systems, they are not 
necessarily identical and the examiner has not shown that Haven discloses an IVR system, as 
specified in the claims. 

Moreover, each of independent claims 16, 21, 27, 32, 38, and 42 specifically recites "an 
application identifier" or "an identifier." In claims 16 and 21, a message is received and that 
message is associated with a call invoking the IVR service, wherein the message specifies an 
application identifier corresponding to a customer application file providing a call plan. 
The customer application file is then retrieved based on the application identifier. Similarly, 
claims 27 and 32 recite, receiving "a request for a customer application file that specifies a call 
plan, the request including an application identifier corresponding to the customer application 
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file." Claims 38 and 42 recite, generating "a customer application file that specifies a call 
plan" and assigning "an identifier to the generated customer application file." 

Applicants respectfully contend that Havens simply does not disclose these claimed 
features. While the Examiner cites col. 1 , lines 39-50, col. 2, lines 1 0-29, col. 3, lines 44-59, 
and col. 4, line 50-col. 5, line 15, it is Applicants' position that the Examiner has misinterpreted 
these portions of Haven. The Examiner states that in Havens, "a sequence of SSLs and SIBs are 
hased upon data associated with a call connection or subscriber data which is associated with an 
IN subscriber. The IN subscriber represents the customer information. The subscription data 
reads on a customer application file since it relates to a specific IN subscriber" (page 1 0 of the 
Final Rejection). However, Havens uses the subscription data associated with a particular 
subscriber to ascertain the identities of the related service script logics (SSLs) of a given IN 
service. The subscription data may not reasonably be read on the claimed "customer application 
file" because the claimed "customer application file" must specify a call plan and there must be 
an "application identifier" that corresponds to the customer application file. Havens ' 
subscription data does not specify a call plan. In fact, Havens' system determines a particular 
call plan only through simulation (see col. 4, line 62 - col. 5, line 2). Applicants can find 
nothing in Havens suggesting that an application file specifies a call plan or that an application 
identifier corresponds to a customer application file, as claimed. 

Thus, it is clear that Havens fails to anticipate independent claims 16, 21, 27, 32, 38, and 
42 as each and every element of the claims, as set forth in the claim, is not taught by the 
reference. Accordingly, these independent claims along with claims 1 7-20, 22-26, 28-3 1 , 33- 
37, 39-41, and 43-45, depending correspondingly therefrom, are in condition for allowance. 
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Therefore, the present application, as amended, overcomes the objections and rejections 
of record and is in condition for allowance. Favorable consideration is respectfully requested. 
If any unresolved issues remain, it is respectfully requested that the Examiner telephone the 
undersigned attorney at (703) 519-9952 so that such issues may be resolved as expeditiously as 
possible. 



Respectfully Submitted, 



DITTHAVONG MORI & STEINER, P.C. 





Attorney/ Agent for Applicant(s) 
Reg. No. 44658 



918 Prince Street 
Alexandria, V A 223 1 4 
Tel. (703)519-9952 
Fax. (703) 519-9958 
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